Method for secure peer-to-peer communication on a blockchain

ABSTRACT

A first blockchain transaction is generated where the first blockchain transaction comprises a redeem script, which comprises a cryptographic public key associated with an initiating party and metadata which includes a hash of an exchange-related document, a redeem address, and an amount of digital currency. A second blockchain transaction to spend the digital currency to the redeem address is generated. A response associated with a responding party and comprising a reference to the exchange-related document is generated. The response is stored in a computer-based repository. A further blockchain transaction is generated, the further blockchain transaction comprising a redeem script, which comprises a cryptographic public key associated with the responding party and metadata which includes a hash of the response and a reference to its location in the repository, and an amount of digital currency.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.16/092,737, filed Oct. 10, 2018, entitled “A METHOD FOR SECUREPEER-TO-PEER COMMUNICATION ON A BLOCKCHAIN,” which is a 371Nationalization of International Patent Application No.PCT/IB2017/052062, filed Apr. 10, 2017, entitled “A METHOD FOR SECUREPEER-TO-PEER COMMUNICATION ON A BLOCKCHAIN,” which claims priority toUnited Kingdom Patent Application No. 1606067.5, filed Apr. 11, 2016,entitled “A METHOD FOR SECURE PEER-TO-PEER LENDING ON A BLOCKCHAIN,” thedisclosures of which are incorporated herein by reference in theirentirety.

This invention relates generally to a tokenisation method and atokenisation system. In particular, it relates to the transfer ofcontracts. It may be suited for use with a P2P lending process. It maybe used in conjunction with any peer-to-peer distributed network. Thismay be blockchain-related technology, including (but not limited to) theBitcoin Blockchain.

In this document we use the term ‘blockchain’ to include all forms ofelectronic, computer-based, distributed ledgers. These includeconsensus-based blockchain and transaction-chain technologies,permissioned and un-permissioned ledgers, shared ledgers and variationsthereof. The most widely known application of blockchain technology isthe Bitcoin ledger, although other blockchain implementations have beenproposed and developed. While Bitcoin may be referred to herein for thepurpose of convenience and illustration, it should be noted that theinvention is not limited to use with the Bitcoin blockchain andalternative blockchain implementations and protocols fall within thescope of the present invention.

A blockchain is a peer-to-peer, electronic ledger which is implementedas a computer-based decentralised, distributed system made up of blockswhich in turn are made up of transactions. Each transaction is a datastructure that encodes the transfer of control of a digital assetbetween participants in the blockchain system, and includes at least oneinput and at least one output. Each block contains a hash of theprevious block to that blocks become chained together to create apermanent, unalterable record of all transactions which have beenwritten to the blockchain since its inception. Transactions containsmall programs known as scripts embedded into their inputs and outputs,which specify how and by whom the outputs of the transactions can beaccessed. On the Bitcoin platform, these scripts are written using astack-based scripting language.

In order for a transaction to be written to the blockchain, it must be“validated”. Network nodes (miners) perform work to ensure that eachtransaction is valid, with invalid transactions rejected from thenetwork. Software clients installed on the nodes perform this validationwork on an unspent transaction (UTXO) by executing its locking andunlocking scripts. If execution of the locking and unlocking scriptsevaluate to TRUE, the transaction is valid and the transaction iswritten to the blockchain. Thus, in order for a transaction to bewritten to the blockchain, it must be i) validated by the first nodethat receives the transaction—if the transaction is validated, the noderelays it to the other nodes in the network; and ii) added to a newblock built by a miner; and iii) mined, i.e. added to the public ledgerof past transactions.

Although blockchain technology is most widely known for the use ofcryptocurrency implementation, digital entrepreneurs have begunexploring the use of both the cryptographic security system Bitcoin isbased on and the data that can be stored on the Blockchain to implementnew systems. It would be highly advantageous if the blockchain could beused for automated tasks and processes which are not limited to therealm of cryptocurrency. Such solutions would be able to harness thebenefits of the blockchain (e.g. a permanent, tamper proof records ofevents, distributed processing etc.) while being more versatile in theirapplications.

One area of current research is the use of the blockchain for theimplementation of “smart contracts”. These are computer programsdesigned to automate the execution of the terms of a machine-readablecontract or agreement. Unlike a traditional contract which would bewritten in natural language, a smart contract is a machine executableprogram which comprises rules that can process inputs in order toproduce results, which can then cause actions to be performed dependentupon those results. Another area of blockchain-related interest is theuse of ‘tokens’ (or ‘coloured coins’) to represent and transferreal-world entities via the blockchain. A potentially sensitive orsecret item can be represented by the token which has no discernablemeaning or value. The token thus serves as an identifier that allows thereal-world item to be referenced from the blockchain. The presentinvention incorporates these concepts to provide a blockchain-basedmechanism which enables secure electronic communication and transferbetween different parties. One advantage of the invention is that itenables the construction and use of a secure communication channelbetween the parties, and incorporation of a securely published contractwithout the need for control, management, intervention or participationby additional parties or entities to oversee the channel.

One illustrative application area for such a solution is that ofpeer-to-peer lending. Lending is an integral part of the financialservices marketplace, allowing borrowers to receive funds from lendersin return for subsequent payment of those advanced funds. Traditionallending via a financial institution such as a bank has, in recent years,been extended through peer-to-peer (P2P) lending where individuals lendpooled finds to a borrower in general for a higher individual return,but with increased risk of loss of the advanced funds.

There are a number of P2P pools with their own bespoke trading exchangesrequiring individual registration onto those applications in order toparticipate in the P2P lending process (e.g. Zopa, Funding circle).These loans are underpinned by the traditional banking network andinfrastructure within the territory that they operate. Therefore, thepresent systems for P2P lending are restrictive and complex by nature.

It would be advantageous to provide an alternative solution. Benefits ofthis solution could include, for example, elimination of the need forlocal bespoke exchanges whilst enabling sophisticated lending processesto be carried out. Known benefits of the blockchain (such as itstamper-proof, permanent record of transactions) could be harnessed toadvantage. This solution would provide an entirely new architecture andtechnical platform. Such an improved solution has now been devised.

Thus, in accordance with the present invention there is provided amethod and system as defined in the appended claims.

Therefore, in accordance with the invention there may be provided amethod and corresponding system for controlling the performance of aprocess conducted via (i.e. using) a blockchain. The block chain may ormay not be the Bitcoin blockchain. The process may be a communication,exchange or transfer process. It may comprise the transfer,communication or exchange of a digital asset, or any type of asset whichis referenced or represented on the blockchain. The controlled processmay, for example, be a lending process. It may be a peer-to-peer lendingprocess conducted between a plurality of blockchain users. The terms“user” or “party” may refer to a human or machine-based entity. Eachblockchain user may use suitably configured hardware and software toparticipate in the process (e.g., a computer with a bitcoin clientinstalled on it). The invention may also be referred to as a securitysolution, system and/or method as it comprises the use of cryptographictechniques to ensure the secure communication/transfer between parties.

The invention may comprise a method substantially as set out in tables 1to 8 included herein, and/or in the use cases/scenarios as set outherein.

Additionally or alternatively, the invention may comprise acomputer-implemented method arranged. It may be arranged to control anexchange process conducted between at least two parties via ablockchain. The method may comprise the steps:

-   -   generating a first blockchain transaction comprising:        -   a redeem script comprising a cryptographic public key            associated with an initiating party and metadata which            includes a hash of a document;        -   a redeem address; and        -   an amount of digital currency;    -   generating a second blockchain transaction to spend the digital        currency to the redeem address.

The document may be an exchange-related document. It may relate to anexchange or transfer to be conducted or communicated between theparties. The exchange may relate to any type of asset, digital orotherwise.

Therefore, the invention may include the step of using a furtherblockchain transaction to spend the currency. This provides theadvantage that the further transaction will be publicly available andthus detectable by other parties once it has been published to theblockchain. The further transaction can provide the informationnecessary to trigger a response e.g. an offer from another party. Thus,the exchange process can be implemented via a multi-transactionmechanism on the blockchain rather than an alternative medium. The firstand second transaction may be generated by the same party. Thetransaction(s) may be multi-signature blockchain transactions. The firstand/or second transaction may provide access from the blockchain to aninvitation (offer/request) which is stored off-block. The invitation maybe an invitation to engage in a contract.

The exchange may be a loan or related to a loan. A smart contract (andassociated blockchain transaction) may be formed upon condition that aplurality of participants e.g. lenders/borrowers are matched with eachother via one or more responses effected via transactions on theblockchain. The invitation may be a structured document stored inelectronic form.

The digital currency may or may not be Bitcoin (BTC). The repository maybe any kind of computer-based resource which is able to store theinvitation. The repository may comprise a server or be housed one aserver. The repository may be separate from the blockchain. Therefore,the invitation may be stored off-block. The reference to the locationmay comprise a URI or other means for identifying the location of theinvitation. The invitation may be publicly available, or some securitymechanism may be used to restrict access to the contents of theinvitation to authorised parties. The invitation may be stored in acentralised location or may be distributed. In a preferred embodiment,the invitation may be publicly accessible and stored on a DistributedHash Table (DHT).

The currency may be any kind of digital currency. It may be Bitcoin. Itmay be tokenised currency. The transfer may be a transfer of any type ofgoods or service. Preferably, the transfer is conducted via theblockchain using a transaction (Tx).

The initiating party may be a potential borrower or lender. Theinvitation may be a document or file which comprises informationrelating to a request or offer for a loan. It may be a digital file. Themethod may include the step of publishing the first transaction to ablockchain.

The invitation may comprise:

information relating to a repayment schedule associated with thetransfer; and/or

a second party associated with the initiating party.

The method may include the step of:

generating a response, the response being associated with a respondingparty and comprising a reference to the invitation;

storing the response in a computer-based repository;

generating a further (multi-signature) blockchain transactioncomprising:

-   -   a redeem script comprising a cryptographic public key associated        with the responding party and metadata which includes a hash of        the response and a reference to its location in the repository;        and    -   an amount of digital currency.

The response may be stored in the same repository as the invitation, ora different repository. The response may be an electronic file. Therepository which stores the invitation and/or response may be adistributed hash table (DHT).

The method may include the step of:

generating an exchange schedule associated with the invitation orresponse, the schedule comprising data relating to at least one exchangeamount and/or exchange date;

generating a P2SH address for each exchange in the schedule.

The exchange schedule may be a repayment schedule. The exchange amountand/or dates may relate to repayments of a loan amount associated withthe invitation or response.

The method may include the step of publishing a transaction to theblockchain to make an exchange in accordance with the exchange schedule.

The method may further comprise the step of monitoring the blockchain toidentify at least one transaction comprising metadata associated withthe invitation and/or response.

At least one monitoring step may be performed substantially as set outin table 2 below.

The method may further comprise the step of:

monitoring the blockchain to identify at least one transactioncomprising metadata associated with the invitation and at least onetransaction comprising metadata associated with the response;

comparing the metadata from the identified transactions to determinewhether there is a correspondence between the metadata.

At least two blockchain transactions may be compared to assess whetherthere is a match (correspondence) between data contained within theinvitation and the response.

The method may further comprise the step of:

generating a smart contract associated with the initiating andresponding party, and comprising data relating to:

the invitation and/or the response;

the initiating party and/or responding party;

a third party such as a guarantor and/or a facilitator;

at least one asset to be transferred from one party to another;

a repayment schedule.

At least one step may be performed substantially as set out in table 4below.

The smart contact may be generated if it is determined that there is amatch (correspondence) between data contained within the invitation andthe response. The smart contract may be generated by an automatedprocess i.e. by computer.

The method may further comprise the step of:

-   -   publishing the smart contract to a repository; and/or    -   publishing a transaction to the blockchain, the transaction        comprising a redeem script comprising at least one public key        and a reference to the smart contract.

The invention may also comprise a computer-implemented system arrangedto perform the method of any preceding claim and comprising:

a blockchain;

a plurality of computing devices arranged for communication with theblockchain.

Additionally or alternatively, the invention may provide acomputer-implemented system arranged and configured to perform any orall of the method steps described above.

Additionally or alternatively, it may comprise a computer-implementedsystem arranged to control a lending process conducted between at leasttwo parties via a blockchain, the system comprising:

a computer-based repository storing an invitation for a transfer betweentwo or more parties; wherein the contract is associated with aninitiating party;

a blockchain comprising a first multi-signature transaction comprising:

-   -   a redeem script comprising a cryptographic public key associated        with the initiating party and metadata which includes a hash of        the invitation and a reference to its location in the        repository; and an amount of digital currency.

Any feature described herein in relation to one aspect or embodiment ofthe invention may also be used in relation to any other aspect orembodiment. For example, a feature described in relation to the methodmay also apply to the system and vice versa.

Thus, the invention may provide various technical benefits including,but not limited to, the following:

-   -   It enables a secure communication channel to be set up between        parties on a peer-to-peer network    -   The communication can be conducted securely between the parties        themselves without the need for intervention by a third party;    -   it enables the control and implementation of a multi-party        exchange or transfer conducted via a blockchain;    -   transfers (such as, for example, repayments) can be made via the        blockchain providing a permanent, tamper-proof and timestamped        record.

These and other aspects of the present invention will be apparent fromand elucidated with reference to, the embodiment described herein.

An embodiment of the present invention will now be described, by way ofexample only, and with reference to the accompany drawings, in which:

FIG. 1 illustrates a P2P network comprising a plurality of computingdevices, as is known in the prior art. The present invention could beimplemented using a P2P system;

FIG. 2 illustrates the relative positioning of each of the parties in.the described key use cases;

FIG. 3 illustrates metadata for Bob who would like to borrow 10bitcoins;

FIG. 4 illustrates metadata for Alice who would like to lend 20bitcoins;

FIG. 5 illustrates the matching of transactions which publish thewillingness of the two participants to enter into a loan on mutuallyagreeable terms;

FIG. 6 illustrates the advancement of a loan by Alice to be drawn downby Bob;

FIG. 7 illustrates an input from Bob to enable him to draw down thefunds advanced by Alice;

FIG. 8 illustrates an input from Bob to repay Alice;

FIG. 9 illustrates an input from Alice to receive Bob's repayment;

FIG. 10 illustrates metadata for Bob who wants to borrow 10 bitcoins,and who intends to provide a guarantor;

FIG. 11 illustrates metadata for Alice who would like to lend 20bitcoins;

FIG. 12 illustrates the matching of transactions which publish thewillingness of Bob and Alice to enter into a loan on mutually agreeableterms;

FIG. 13 illustrates the advancement of a loan by Alice to be drawn downby Bob;

FIG. 14 illustrates an input from Bob to enable him to draw down thefunds advanced by Alice;

FIG. 15 illustrates an input from Bob to repay Alice;

FIG. 16 illustrates an input from Alice to receive Bob's repayment;

FIG. 17 illustrates metadata for Bob who wants to borrow 30 bitcoins;

FIG. 18 illustrates metadata for Alice who would like to lend 10bitcoins;

FIG. 19 illustrates metadata for Eve who would like to lend 20 bitcoins;

FIG. 20 illustrates a matching process which takes place which publishesthe willingness of the three participants to enter into a loan onmutually agreeable terms.

FIG. 21 illustrates Bob locking the required collateral into an escrowaccount owned by the facilitator;

FIG. 22 illustrates the construction of a contract document containingthe negotiated terms;

FIG. 23 illustrates an input from Bob to drawdown a loan advanceprovided by Eve and Alice;

FIG. 24 illustrates an input from Bob to repay Alice and Eve;

FIG. 25 illustrates an output repaying Alice and Eve;

FIG. 26 illustrates an input from Bob to reclaim collateral;

FIG. 27 illustrates metadata from Bob to indicate Bob's desire to borrow£15,000;

FIG. 28 illustrates metadata from Alice indicating a desire to lend£15,000;

FIG. 29 illustrates a matching process which publishes the willingnessof Bob and Alice to enter into a loan on mutually agreeable terms;

FIG. 30 illustrates the construction of a contract document containingthe negotiated terms;

FIG. 31 illustrates an input from Bob to draw down a loan advance fromAlice;

FIG. 32 illustrates an input from Bob to make a repayment to Alice;

FIG. 33 illustrates an input from Alice to collect a repayment from Bob.

FIG. 1 shows a P2P network in accordance with the prior art. A P2Psystem is a distributed architecture which shares work and tasks betweeninterconnected computing devices, which are known as ‘nodes’ or ‘peers’.Such a network is decentralised in that no individual computer isdesignated as being ‘in charge’. In recent years, P2P architecture hasbeen used for the implementation of the Bitcoin Blockchain andBitcoin-inspired adaptations.

The following terms may be used herein and may be construed inaccordance with the following meanings:

Name Type Borrower The Borrower is an actor or entity, which may be anindividual or corporate entity, or computer-based resource, which isseeking the loan of money or other assets for a period of time. Morethan one Borrower can be engaged in a given loan. Guarantor TheGuarantor is an actor/entity (or one of the actors) that is underwritingthe loan in circumstances where the Borrower's credit rating (asdetermined by the Lender's) is perceived to be too weak to support theadvancement of the loan without this additional surety. Lender TheLender is an actor/entity, which may be an individual or corporateentity, or computer-based resource, which is advancing the loan of moneyor other assets for a period of time in return for a set of repayments.Facilitator The Facilitator is an actor/entity, which may be anindividual or corporate entity, which acts as an intermediary betweenthe Lender(s) and Borrower(s) in the arrangement, or ongoing managementof the Loan. Repository The Repository is an actor, which may be anindividual or corporate entity, or a computer-implemented resource,which acts as a trusted repository for any documents (e.g. offer,request, rule or contract) which is referenced within the loanarrangement or management. Document The Document is an entity thatcontains structured information relevant or related to the loan process;it may be a digital document e.g. a computer file; it may be astructured document Offer Request This is a specialised type of Documentthat contains details of the offer made by a Lender or the request madeby a prospective Borrower to the market. By itself, this document is notbinding but merely publishes information enabling multiple parties toagree on mutually acceptable terms for a loan. Bound Contract This is aspecialised type of Document that contains a formal agreement betweenthe various Lenders/Borrowers/Guarantors setting out the terms of a loanbetween these actors. Repayment This is a specialised type of Documentthat contains the formal definition of Rule the rule that determines howto calculate one or more repayment against a loan. Initiator This is anactor/entity that is the first to create a loan offer/request onto theBlockchain. The invention described herein allows either the Borrower orthe Lender to be the initiator for a particular loan. It should be notedthat both the lender and the borrower can be the Initiator for a loansimultaneously; in this situation either party, or the Facilitator willdetect the other parties Offer Request and mediate to create anacceptable loan contract. Responder This is an actor/entity thatgenerates a response to a loan offer/request that has been generated bythe Instigator

We now outline the key concepts of an illustrative embodiment of thepresent invention. The example used herein relates to a lending process,but the invention is not limited in his regard. In brief, thisillustrative embodiment provides a technical solution for allowing thepublication of a prospective contract—from either a borrower or alender—to a blockchain in manner that allows counterparties to bind tothat contract, or offer alternative terms to that contract. Knownsolutions do not provide a technical mechanism for performing theseoperations in the manner described herein.

It should be noted that a contract will only be formed when mutuallyacceptable terms between the borrower and lender(s) are agreed on. Ifinsufficient funds are put forward to meet a borrower's requirements, nocontract is formed.

The key elements of the inventive process are outlined as follows.

-   -   The initiator publishes a proposed contract onto the Blockchain,        the proposed contract states:    -   What they want to borrow;    -   The amount they want to borrow; and    -   The repayment frequency and terms.

The contract is published publicly on the blockchain via a transactionwhich comprises a pointer or reference to the location of the contractand a hash of the contract. The contract itself is held off-block (i.e.not within the blockchain) and details could include the interest rates,location, and asset details. Therefore, in reality, the contract itselfmay not be published in the blockchain but represented and/or accessiblevia metadata in a transaction on the blockchain. The contract may bevery complex but sortable based on the data provided. The contractitself may be held in a computer-based registry or repository which may,in some embodiments, be implemented as a Distributed Hash Table (DHT)with the hash of the contract serving as a look-up key.

In one example, peers would be able to use software tools to observe andsearch the blockchain to find a particular type of loan, look at theirinterest rates, and interrogate the payment schedule. Having access tothis information allows potential investors to calculate the risk anddecide on which contracts they wish to bid. In this way, the inventionprovides the significant benefit that information relating to loans orpotential loans can be made easily and freely available.

Potential counterparties bid in one of two mechanisms:

1) either on the same basis as an assurance contract (although this isonly viable where the borrower is the initiator); In the case of theassurance contract model, this means the borrower has only the setperiod defined in the contract to raise the funds. Take the example of acontract wishing to raise 15 bitcoins in 30 days. User A bids eightbitcoins, user B bids two bitcoins, and user C bids five bitcoins.Provided all three bids arrive within the 30 day period, the contract isvalid. However if User C's bid is not forthcoming before the 30 daytimetable, the contract ends and no further action is taken because only10 Bitcoins have been pledged

or:

2) using the same mechanism as the initiator, wherein a contract isbroadcast to the blockchain. On a broadcast basis, the contract itselfwill determine the validity period of any offers made.

Once the total of all the bids equals the requested loan amount, theblockchain Transaction becomes valid. The validation process can beperformed by informally circulating a copy of an incomplete (andtherefore not yet valid) Transaction. e.g. by publishing it to apublicly accessible place such as a repository. Prospective lenders canthen pledge currency such as BTC by taking a copy of the incompletetransaction and creating a new version that has (in separate Inputsections of the Transaction) their pledged amount. The Transactionremains invalid until the total amount of all pledges reaches thethreshold specified in the Output section. However, once the totalexceeds the threshold the Transaction becomes valid and may be Broadcastto the network. This technique uses the ‘ANYONE-CAN-PAY’ flag.

In the present case, the smart contract is published to the Blockchainonce it becomes valid. The Transaction includes:

-   -   The terms covered by a smart contract; and    -   The money, either in Bitcoin or tokenised format, is released to        the borrower from the investors.

A loan note is issued detailing what has been borrowed. This isimplemented as a Transaction. This is sent back to the borrower'sPay-to-Script Hash (P2SH) address. The borrower must provide a scriptthat matches this hash address to enable them to spend the loaned money.The P2SH address also includes details of all the repayments. Thedetails of the repayments are embedded as metadata in the redeem script.

If the contract includes regular repayments, a schedule of these iscreated. The P2SH address for each payment is created to repay theinvestors. For example, for a regular payment of one Bitcoin where UserA puts in 50%, User B puts in 30%, User C puts in 20%, the followingamounts are paid to each user:

User A: 0.5 Bitcoin

User B: 0.3 Bitcoin

User C: 0.2 Bitcoin

Each repayment is made in turn and the corresponding transactiontimestamped in accordance with known blockchain techniques. Therepayment could be split between the actual repayment amount and anyinterest incurred. This enables any party involved in the loan to see,via the blockchain, if and when a payment has been made. It is alsopossible for the borrower to pay a scheduled payment early and for thisto be visible in the timestamp. Therefore, the invention provides anenhanced mechanism for sharing and exchanging loan-related data via ablockchain.

Some example scenarios are now provided for illustration only and arenot intended to be limiting.

Example Scenario One—Standard Loan with No Guarantor or Collateral

This scenario is described with reference to FIGS. 3 to 9 . Suppose thatBob requires a loan of 10 bitcoins (BTC) but has no collateral to secureit. He requires the loan to have:

-   -   a one year rate    -   Monthly repayments    -   10% interest rate

Bob generates transaction metadata using a suitably programmed computing(client) device and provides the metadata in a pay-to-script-hash (P2SH)in a blockchain transaction as illustrated in FIG. 5 . The metadatagenerated by Bob is illustrated in FIG. 3 .

In such scenarios the borrower's own reputation is used as collateral.The prospective lenders have multiple routes to evaluate Bob's creditworthiness either using information supplied as part of the requestdocument or directly from the Blockchain which would allow the loan tobe advanced in a pseudo-anonymous manner. Methods of assessing creditworthiness are beyond the scope of the present invention, and the way inwhich the borrower's credit worthiness is assessed is not relevantherein.

Only when the required amount has been raised is a repayment schedulecreated, with the line of credit maintained in a two line signatureaddress:

-   -   Borrower    -   Investor

Each of the monthly payments will be made to the investor's signatureaddress. The payment amount is calculated according to the outstandingbalance and interest to be paid. If the 10 bitcoins are not raised, thecontract is deemed invalid.

Alice generates metadata indicating her willingness to lend 20 bitcoinsfor up to 60 months at a minimum interest rate of 9% with no collateral.The metadata generated in respect of Alice's willingness to enter intosuch an agreement is illustrated in FIG. 4 .

Bob's desire to borrow the 10 bitcoins and Alice's willingness to lend20 bitcoins are published as transactions to the blockchain, as set outin FIG. 5 . The transactions generated in respect of Bob and Alice arematched and a contract is formed in the form of a loan advanced by Alice(see FIG. 6 ). Bob's repayment of the loan is shown in FIG. 8 . FIG. 9illustrates Alice receiving the repayment from Bob.

‘Matching’ may be interpreted as meaning that there is a mirroring of atleast one item or element in the respective transactions i.e. there iscorrespondence between the respective transactions. The skilled personwill understand that the matching process can be performed in a varietyof ways. In one embodiment, it is performed using a simple algorithmwhereby the Request-values from the borrower are matched up against thecorresponding offer-values from the lender. This can be done by ensuringthat the min-max ranges overlap (where the values are expressed inranges) or that the actual values match up directly (i.e. that bothrequest and offer are for BTC or both for a particular token, etc.).

Scenario Two—Standard Loan with a Guarantor

Bob requires a loan of 10 bitcoins, but has no collateral to secure it.As he is aged 14 and therefore considered a minor, he does not have astrong Blockchain reputation. Instead Bob gets his mother, Eve, to actas a guarantor. The metadata illustrated in FIG. 10 is generated inorder to describe this input. The information shown in FIG. 10 ,contained within the metadata, could be used to facilitate a check ofBob and Eve's reputation.

It should be noted that conditions of any type can be attached to thecontract. This is achieved by maintaining a separate list of conditioncodes. In the example of FIG. 10 , the condition code used to indicate‘guarantor’ is (arbitrarily) set to ‘0x0003’. The first two bytes of themetadata indicate what the condition code is, and the rest of themetadata is formatted depending on the value of the condition code. Theformatting is specified in the separate list of condition codes. In theexample of FIG. 10 , the next 20 bytes of metadata represent the hash ofthe guarantor's public key.

Only when the required amount has been raised is a repayment schedulecreated, with the line of credit maintained in a three line signatureaddress:

-   -   Borrower    -   Investor    -   Guarantor

Each of the monthly payments is made to investor's signature address.The payment amount is calculated according to the outstanding balanceand interest to be paid. If the 10 bitcoins are not raised, the contractis deemed invalid.

Alice generates metadata as shown in FIG. 11 , indicative of her desireto lend 20 bitcoins for up to 5 years at a minimum interest rate of 9%with no collateral.

FIG. 12 shows the requests which are generated as a result of Bobindicating a desire to borrow 10 bitcoins and Alice indicating a desireto lend 20 bitcoins. The two requests are matched and then a contract isconstructed. This contract is a loan of 10 bitcoins advanced by Alice.The loan is for 10 bitcoins at a rate of 9% per annum over 12 months.This is shown in FIG. 13 .

Bob's loan drawdown is shown in FIG. 14 . Bob's repayment is shown inFIG. 15 . Alice's repayment is shown in FIG. 16 .

Example Scenario Three—Using Assets as Collateral

Andrew wants to borrow 60 bitcoins in order to fund an extension beingbuilt on his house. He decides to put up 5% of the house's mortgage ascollateral for the loan. Andrew is known by his ID, which is included inthe metadata for his request. This makes it easy to establish what hiscredit rating is. Potential lenders are able to interrogate Andrew's keypair for previous blockchain transactions where he has borrowed moneyand repaid loans. From this they can decide if it is worth making a bid.The metadata for Andrew's request is shown in FIG. 17 .

Ownership of the house's title deeds is tokenised (i.e. represented inmetadata in a blockchain transaction) enabling users to easily swapownership of the 5% mortgage. The system is then used to broadcast theneed to raise the 10 bitcoin. Only when the required amount has beenraised is a repayment schedule created, with the line of creditmaintained in a two line signature address containing details of theBorrower and Investor.

When repayments are made, each of the lender addresses will be paid inthe shares allocated for the investment. For example, if there are twolenders with a 60/40 split in the amount being lent, one lender wouldget 60% of the repayment and the other 40%. The redeemable contractlinks the repayment to the pay to borrower's script hash address.

Alice would like to lend 10 bitcoins up to 5 years at a minimum interestrate of 9% but would like security. The metadata generated by thisrequest is shown in FIG. 18 .

Eve would like to lend 20 bitcoins for up to 5 years at a minimuminterest rate of 9.75%. The metadata generated for this request is shownin FIG. 19 . The transactions generated by Bob, Eve and Alice are thenmatched off as illustrated by FIG. 20 .

Bob then supplies collateral in a transaction as illustrated in FIG. 21. The advancement of the funds by Alice and Eve is shown by FIG. 22 .

The drawdown of the advanced funds is shown in FIG. 23 . The repaymentof the loan by Bob is shown in FIG. 24 .

The collection of the repayment by Alice and Eve is shown in FIG. 25 .The reclaim of the collateral by Bob is shown in FIG. 26 .

Example Scenario Four—Borrowing Fiat Currency

Andrew wants to borrow £15,000 but wishes to manage his account via theBlockchain. The metadata generated in respect of Andrew's request isshown in FIG. 27 . In this scenario, the Lender lends a tokenisedcurrency rather than ‘raw’ Bitcoins to advance the funds.

Alice indicates in a request that she would like to provide a loan onthe Blockchain for 12 months with monthly repayments at a rate no lessthan 10%. The metadata generated in response to this request is shown inFIG. 28 .

Bob's request and Alice's offer are both published on the blockchain asshown in FIG. 29 . The advancement of the funds from Alice is shown inFIG. 30 . The drawdown of the loan by Bob is shown in FIG. 31 .

The repayment of the loan by Bob is shown in FIG. 32 . The collection ofthe repayment by Alice is shown in FIG. 33 .

Technical Specification

At its simplest, a loan is an arrangement between a Lender and aBorrower for the Lender to advance money, or other asset, to theBorrower. The present invention utilises a blockchain as a technicalvehicle for exchanging and publishing these assets and agreements. Whilethe description herein focusses on the lending of BTC, or tokenisedcurrency facilitated by BTC, it should be noted that the invention isnot thus limited and other currencies or blockchain protocols may beused.

The invention may confer the following advantageous features, amongstothers:

-   -   it enables offers and/or requests to facilitate a loan to be        published onto the Blockchain, with supporting information held        elsewhere;    -   it enables loan contracts to be published onto the Blockchain,        with additional supporting information held elsewhere    -   it enables multiple lenders to participate in a loan    -   it enables multiple borrowers to participate in a loan    -   it enables a borrower can underwrite a loan with one or more        guarantors    -   it enables a borrower to underwrite a loan through the provision        of supporting collateral, where that Collateral can be hosted on        the Blockchain, or outside it    -   it enables a loan contract to have any nature of variable        repayments, and repayment calculations specified against it and        the system enables this underlying infrastructure to be        implemented using the blockchain    -   it enables competitive bidding between lenders to take place    -   it enables competitive bidding between borrowers to take place    -   it enables either the Borrower or the Lender to be the initiator        for a particular loan.

We now describe a series of key use cases for the purposes ofillustration.

Initiation of a Loan

A Borrower or Lender (initiator) wishes to publish an offer to the widermarket about a loan that (s)he wishes to enter into.

TABLE 1 Step Details 100.10 To publish a loan offer, the Initiatorcreates a new Offer Request document which it publishes to a Repositoryeither directly, or via a Facilitator. A secure hash of this Requestdocument is created, plus the location of that document. Included withinthis document is information about: Initiator (either the Borrower orthe Lender depending on which actor initiated the request) LoanRequested or Offered Repayment Terms Requested or Offered 100.20 Thissecure hash and location is used to create the relevant metadata blocksto include within the bitcoin offer transaction 100.30 The Initiatorthen creates a new Redeem Script using this metadata plus their publickey. This will be a m of n multi-signature transaction where: m is 1;and n is m plus the number of metadata blocks included. 110.40 TheInitiator then creates a new Bitcoin transaction which is sent to thepreviously calculated redeem script. The value of BTC included withinthis transaction must be a minimum of the current dust value plus twicethe minimum mining fee. 110.50 The Initiator then uses anothertransaction to reclaim the BTC back to the Initiator from the redeemaddress using, the metadata blocks plus signatures from the Initiator.This transaction then contains the information to trigger offers fromother interested parties. The value of BTC included within thistransaction must be a minimum of the current dust value plus the minimummining fee.

Extensions

There are two extensions to this use case:

-   -   [110] Request Loan with Guarantor; in this situation the request        must come from a Borrower    -   [120] Request Loan with Collateral

Variations

This use case has a variation [105] where a Facilitator is involved inthe management of the loan request. The scenario involves the followingsteps:

Step Details 105.10 Step 100.10 is amended such that it may be performedby the Facilitator using information supplied by the Initiator. 105.30Step 100.30 is amended such that the transaction in this step uses thepublic key of the Facilitator rather than the key of the Initiator105.50 Step 100.50 is amended such that this step is performed by theFacilitator to collect the BTC from the Initiator as their listing fee.The transaction can still be used by any prospective counterparties asbefore.

Borrower Requests Loan with Guarantor

In this example use situation, the borrower wishes to supply informationabout guarantors that are prepared to underwrite the loan request.

Step Details 110.10 Step 100.10 is amended such that additionalinformation is included within the Request document to include thefollowing information: Guarantor(s) 110.30 Step 100.30 is amended suchthat the Borrower then creates a new Redeem Script using this metadataplus their public key and the public keys of each Guarantor included.This will be a m of n multi-signature transaction where: m is 1 plus thenumber of Guarantors; and n is m plus the number of metadata blocksincluded. 110.50 Step 100.50 is amended such that the Borrower andGuarantors then reclaim the BTC back to the Borrower from the redeemaddress using the metadata blocks plus signatures from the Borrower andeach Guarantor. This transaction then contains the information totrigger offers from Lenders. The value of BTC included within thistransaction must be a minimum of the current dust value plus the minimummining fee.

Loan Request with Collateral

In this example the borrower wishes to include information aboutcollateral they are prepared to offer as security to the prospectivelenders.

The scenario is as described but with the following amendments.

Step Details 120.10 Step 100.10 is amended such that the Borrowerincludes the following additional information inside the Request:Collateral

This use case has a variation [125] where the collateral being offeredis managed directly on the Blockchain. The scenario is as described for[120] with the following amendments.

Step Details 125.30 Step 100.30 is amended such that in addition to theloan metadata, plus public keys, the metadata associated with the assetbeing offered as collateral is included as well.

Monitoring a Blockchain

In this example a prospective loan participant, i.e. either a Borrower,a Lender or a Facilitator, needs to ensure that they are aware of newrequests that are published onto the Blockchain.

TABLE 2 Step Details 200.10 Either the Responder or the Facilitator readthe Blockchain to detect new transactions that contain the relevantmetadata information identifying a loan request/offer. Variation: Thisscan could use uncommitted transactions rather than monitor thepublished Blockchain itself. 200.20 Since the transaction metadatarepresents a generic contract, many transactions that include metadatawill not be of interest to the Responder or Facilitator. As a result,this step triages the transactions to actively discard those that do notmeet the criteria defined by the Responder/Facilitator. 200.30 Where themetadata blocks do not contain enough information by themselves todetermine whether a response should be generated, theResponder/Facilitator uses the contract link within the metadata tocollect the structured offer/response document from the relevantRepository. 200.40 The Responder/Facilitator will now determine whetheror not to proceed based on the information within the metadata andstructured document.

Responder Responds to Loan

In this example a responder wishes to respond to a loan offer and/orrequest that has been published in the Blockchain.

TABLE 3 Step Details 300.10 The Responder uses the informationconstructs a response to the offer request published on the Blockchain.There is no requirement for the response to explicitly match theoriginal request. 300.10 To publish a response, the Responder creates anew Offer Request document which it publishes to a Repository eitherdirectly, or via a Facilitator. A secure hash of this Request documentis created, plus the location of that document. Included within thisdocument is information about: Reference to the original Offer Requestdocument that triggered this response Responder (either the Borrower orthe Lender depending on which actor initiated the request) LoanRequested or Offered Repayment Terms Requested or Offered 300.20 Thissecure hash and location is used to create the relevant metadata blocksto include within the bitcoin offer transaction. 300.30 The Responderthen creates a new Redeem Script using this metadata plus their publickey. This will be a m of n multi-signature transaction where: m is 1;and n is m plus the number of metadata blocks included. 300.40 TheInitiator then creates a new Bitcoin transaction which is sent to thepreviously calculated redeem script. The value of BTC included withinthis transaction must be a minimum of the current dust value plus twicethe minimum mining fee. 300.50 The Initiator then reclaims the BTC backto the Initiator from the redeem address using the metadata blocks plussignatures from the Initiator. This transaction then contains theinformation to trigger offers from other interested parties. The valueof BTC included within this transaction must be a minimum of the currentdust value plus the minimum mining fee.

There is one major variant to this use case where the response is (a)from a Lender and (b) a direct 1:1 match for the request (effectively abilateral loan). In this situation, the Lender may actually advance thefunds to a drawdown account in one step.

Matching Details

In this example, the Facilitator wishes to match prospective loanrequests and/or loan offers to create a binding contract between theinterested parties, in return for a payment for the Facilitator'sservices.

Main Success Scenario

TABLE 4 Step Details 400.10 Using information on offers & requests thathave been published on the Blockchain, construct a ContractBindingdocument containing the details of a valid loan, including the followinginformation within the document: Originating OfferRequest documents;Borrower Details; Any Guarantor Details; Any Collateral Details;Information about the funds to be advanced to the Borrower Informationabout the funds received from each Lender Information about the agreedrepayment schedule 400.20 This ContractBinding document is published toa Repository and the hash of the document, plus the associated URI forits published location is retained. 400.30 The contract metadata for theloan is constructed from the ContractBinding document. Where funds otherthan BTC are being advanced, metadata detailing the assets beingadvanced are sourced. Where collateral managed on the Blockchain isbeing utilised, metadata detailing those assets are sourced. 400.40 Aredeem script hash address for loan drawdown is constructed using a m ofn multi- signature construct where: m is 2 plus the number ofguarantors; the issuer of the asset being advanced (where required totransfer ownership); the issuer of the collateral being utilised (whererequired to transfer ownership) n is m plus: the number of metadatablocks associated with the loan referencing the ContractBinding documentgenerated in 400.30; the number of metadata blocks associated with theasset being advanced; and the number of metadata blocks associated withthe collateral. The script itself will contain the following: metadataof the loan; (optional) metadata of the asset being lent; (optional)metadata of the asset being used as collateral; public key of theBorrower public key of the Facilitator; (optional) public key of theIssuer of the asset being lent if required to facilitate transfer ofthat asset; (optional) public key of the Issuer of the asset beingutilised as collateral, if required to facilitate transfer of that asset400.50 A transaction is published to each of the Lenders with notransaction inputs defined with the output defined as the addressderived in step 400.40 above.

Advancing Funds

In this example, the lender would like to advance the funds for the loanto the borrower such that they can only be drawn down in accordance withthe agreed terms.

TABLE 5 Step Details 500.10 Each Lender receives an outline transactionfrom the Facilitator and allocates the relevant transaction inputs tocover the transaction, and then signs the transaction using theirprivate key 500.20 Optional If required to transfer ownership of theassets being transferred (for example where the loan is for anythingother than BTC), the Lender gets the asset Issuer to countersign thetransaction using the Issuer's private key. 500.30 Optional Each lendermay also create a reversing transaction for a given date/time in thefuture with the same inputs allocated in step 500.10 to recover thefunds if not drawn-down by that time. This reversing transaction mayalso require signing by the Issuer of any underpinning assets. 500.40The signed transaction(s) are then committed to the Blockchain whichlocks the funds into a drawdown account that requires the Borrower,Guarantors and Facilitator to sign to drawdown the funds.

Advancing Collateral

In this example, the borrower would like to place the agreed collateralfor the loan into an escrow facility in order to receive the loan.

TABLE 6 Step Details 600.10 The Borrower creates a new redeem scriptwith a m of n multi-signature construct where: m is 2 plus: the count ofthe public keys required from the Lender(s). Note that this is probablyonly practical in a situation where the loan is bilateral (or has alimited number of lenders since the limit on signature numbers will berestrictive otherwise) (optional) the count of the public keys requiredby the Issuer of the underpinning asset n is m plus: count of themetadata blocks associated with the loan contract; plus o count of themetadata blocks associated with the asset used as security 600.20 TheBorrower creates a transaction, using the appropriate inputs from theirportfolio to pay the collateral to this redeem script. The Borrowersigns this transaction using their private key. 600.30 If the assetbeing transferred requires a signature from the Issuer then the Borrowerforwards this transaction to the Issuer who signs it using their privatekey. 600.40 The transaction is then committed to the public Blockchain.

Drawdown Advanced Loan Funds and Entering into the Loan Agreement

In this example the borrower wishes to drawdown the advanced funds andenter into the loan agreement.

Step Details 700.10 Once the Facilitator determines that enough fundshave been advanced, then they will construct a drawdown transaction forthe Borrower. The nature of this transaction will differ depending onwhether the advance is of BTC, or an alternative asset managed on theBlockchain. 700.20 For a BTC loan transaction, the transaction output issent to the Borrower's public key address. 700.30 For an asset loantransaction, a redeem script address is created using a m of n multi-signature construct where: m is 2 if the Issuer is required tocountersign asset transfers or 1 otherwise n is m plus the count of thenumber of asset metadata blocks included within the transaction 700.40The Facilitator then checks to determine that any collateral has beenlodged within the approved escrow address by scanning the Blockchain forthe committed transaction 700.50 Once the collateral has been lodged (oris not required), then the Facilitator signs the drawdown transaction,and passes the transaction to the Borrower to countersign 700.60 TheBorrower countersigns the transactions and publishes it to theBlockchain.

Repayment

In this example the borrower would like to make repayments against theloan in accordance with the agreed terms and conditions.

Step Details 800.10 Any of the parties engaged within the loan may takeresponsibility for the calculation of repayment amounts due. Theassumption is that, for most loans, this would be undertaken by theFacilitator to simplify the model. In either situation, the nextrepayment is read from the metadata associated with the loan. Where therepayment schedule is complicated, this is determined from theContractBinding document referenced within the metadata, although forsimple loans the metadata itself can contain enough information toperform the calculation directly. 800.20 A repayment script address isgenerated for the borrower in the form of a m of n multi- signatureaddress, where: m is 1, or 2 is there is a requirement for an Issuer tocountersign asset transfers n is m plus the count of the number of loanmetadata blocks plus the count of the number of asset metadata blocksThe transaction itself includes the public key of the Facilitator plusoptionally the public key of the Issuer if their authority is requiredfor asset transfers 800.30 A transaction, with no transaction inputs, isgenerated to pay the amount calculated in step 800.10 to the addresscalculated in 800.20 800.40 The transaction is passed to the Borrowerthat enriches the outline transaction with details of the transactioninputs used which may also include adding a change output to thetransaction. 800.50 The Borrower then signs the transaction 800.60 Ifrequired, the Borrower arranges for the Issuer to countersign thetransaction 800.70 The transaction is published onto the Blockchain800.80 The Facilitator then splits the repayment between the variousLenders in proportion to their ownership of the loan. For each Lender,the Facilitator creates a redeem script in the form of a m of nmulti-signature where: m is 1, or 2 if there is a requirement for theIssuer to countersign asset transfers n is m plus the count of thenumber of loan metadata blocks plus the count of the number of assetmetadata blocks The transaction itself injects the public key of theindividual Lender plus optionally the public key of the Issuer. 800.90The Facilitator then creates a repayment transaction for each Lender,and injects the loan and asset metadata (where applicable) beforesigning the transaction. 800.100 (Optional) Where asset transfersrequire the signature of the Issuer, then the transaction is passed tothe Issuer to sign 800.110 The Facilitator publishes the repaymenttransaction onto the public Blockchain.

Release Collateral

In this example the borrower would like to have the collateral that wasused to secure the loan released once the terms of the loan have beenfulfilled.

Step Details 900.10 Once the Facilitator completes the repaymentschedule defined within the ContractBinding structure (or for simpleloans within the metadata attached to the transaction itself), it willautomatically release the collateral out of the escrow account. 900.20The Facilitator will create a redeem script in the format of m of nwhere: m is 1, or 2 where the Issuer is required to countersign assettransfers n is m plus the count of the metadata associated with theasset The metadata of the asset, plus the Borrower's public key will bethe source keys for the script. 900.30 The Facilitator will sign theredemption transaction with the metadata of the asset, the metadata ofthe loan and their public key. 900.40 (Optional) Where required, theIssuer will countersign the transaction. 900.50 The transaction will bepublished to the Blockchain to release the assets back into the controlof the Borrower.

Facilitator/Lender Merging

The above Use Cases describe the facilitator and the lender as separateentities. However, in a number of real-world scenarios, the facilitatorand the lender could be the same entity. This does not alter the stepsrequired but simplifies the development complexity.

Facilitator Removal

The use cases above rely on a Facilitator agent to broker thetransactions between the lender and the borrower. Whilst in the abovescenarios, the facilitator can be argued as adding material value to theprocess for both the lenders and the borrowers (in terms of facilitatinga negotiation, and determining repayments), it is possible to use theAssurance Contract mechanism to advance funds directly from the lendersto the borrowers. In this scenario:

-   -   The borrower is responsible for generating the drawdown script        address. As this is functionally deterministic, the lenders are        also capable of validating that the script address generated        matches the metadata associated with the proposed loan.    -   The lender's loan transaction is then tweaked slightly:        -   The lender's input is explicitly that of the loan being            advanced with no change. This may require the lender to            advance in two transactions; one to generate an output with            the explicit target input value and then the second one to            advance the loan        -   The output value is the total value of the loan requested            regardless of the amount of the advance from the given            lender        -   The input signature is signed using            SIGHASH_ALL|SIGHASHANYONECANPAY which means that signing is            restricted to the lender's input and not all of the inputs            for the transaction.    -   The Borrower can then drawdown the loan at any point when enough        funds have been committed to the pool from various lenders.

It should be noted that the above-mentioned embodiments illustraterather than limit the invention, and that those skilled in the art willbe capable of designing many alternative embodiments without departingfrom the scope of the invention as defined by the appended claims. Inthe claims, any reference signs placed in parentheses shall not beconstrued as limiting the claims. The word “comprising” and “comprises”,and the like, does not exclude the presence of elements or steps otherthan those listed in any claim or the specification as a whole. In thepresent specification, “comprises” means “includes or consists of” and“comprising” means “including or consisting of”. The singular referenceof an element does not exclude the plural reference of such elements andvice-versa. The invention may be implemented by means of hardwarecomprising several distinct elements, and by means of a suitablyprogrammed computer. In a device claim enumerating several means,several of these means may be embodied by one and the same item ofhardware. The mere fact that certain measures are recited in mutuallydifferent dependent claims does not indicate that a combination of thesemeasures cannot be used to advantage.

1. A computer-implemented method arranged to control a secure exchange and/or communication process conducted between at least two parties via a blockchain, the method comprising: generating a first blockchain transaction comprising: a redeem script comprising a cryptographic public key associated with an initiating party and metadata which includes a hash of an exchange-related document; a redeem address, and an amount of digital currency; generating a second blockchain transaction to spend the digital currency to the redeem address; generating a response, the response being associated with a responding party and comprising a reference to the exchange-related document; storing the response in a computer-based repository; and generating a further blockchain transaction comprising: a redeem script comprising a cryptographic public key associated with the responding party and metadata which includes a hash of the response and a reference to its location in the repository; and an amount of digital currency.
 2. A system according to claim 1 and further comprising a step of: publishing the first and second transactions to a blockchain.
 3. A method according to claim 1 wherein the exchange-related document is an invitation to perform a transfer between two or more parties.
 4. A method according to claim 3 wherein the invitation comprises one or more of: information relating to a repayment schedule associated with the transfer; and a second party associated with the initiating party.
 5. A method according to claim 1 wherein the repository is a distributed hash table.
 6. (canceled)
 7. A method according claim 1 and comprising the step of: generating an exchange schedule associated with the exchange-related document and/or the response, the schedule comprising data relating to at least one exchange amount and/or exchange date; and generating a P2SH address for each exchange in the schedule.
 8. A method according to claim 7 and comprising a step of: publishing a transaction to the blockchain to make an exchange in accordance with the exchange schedule.
 9. A method according to claim 1 wherein the exchange-related document and/or response is a document stored in a digital format.
 10. A method according claim 1 and further comprising the step of monitoring the blockchain to identify at least one transaction comprising metadata associated with the exchange-related document and/or response.
 11. A method according to claim 1 and comprising the step of: monitoring a blockchain to identify at least one transaction comprising metadata associated with the exchange-related document and at least one transaction comprising metadata associated with the response; comparing the metadata from the identified transactions to determine whether there is a correspondence between the metadata.
 12. A method according to claim 5 and comprising the step of: generating a smart contract associated with the initiating and responding party, and comprising data relating to: the exchange-related document and/or the response; the initiating party and/or responding party; a third party such as a guarantor and/or a facilitator; at least one asset to be transferred from one party to another; and a repayment schedule.
 13. A method according to claim 11 and further comprising the step of: publishing a smart contract to a repository; and/or publishing a transaction to the blockchain, the transaction comprising a redeem script comprising at least one public key and a reference to the smart contract.
 14. A computer-implemented system arranged to perform the method of claim 1 and comprising: a blockchain; and a plurality of computing devices arranged for communication with the blockchain.
 15. A computer-implemented system arranged to control an exchange process conducted between at least two parties via a blockchain, the system comprising a blockchain comprising: a first blockchain transaction comprising: a redeem script comprising a cryptographic public key associated with an initiating party and metadata which includes a hash of an exchange-related document; a redeem address; and an amount of digital currency; a second blockchain transaction arranged to spend the digital currency to the redeem address; generating a response, the response being associated with a responding party and comprising a reference to the exchange-related document; storing the response in a computer-based repository; and generating a further blockchain transaction comprising: a redeem script comprising a cryptographic public key associated with the responding party and metadata which includes a hash of the response and a reference to its location in the repository; and an amount of digital currency. 